ci: add issue welcome issue - #4127
Conversation
c458d05 to
4ee87bd
Compare
There was a problem hiding this comment.
Thanks for thinking about how we can make take / untake easier for contributors to discover.
Since this would add an automated comment to every newly opened issue, I think the behavior itself would be better discussed with the community before we decide on the implementation. The commands are already documented in the contributing guides, so it would also be useful to establish whether there is still a discoverability gap and whether an automatic comment is the preferred way to address it.
Would you mind opening a Discussion for this proposal and linking it here? That would give contributors and maintainers a place to weigh the onboarding benefit against the additional notification and issue noise. This is a suggestion about where to make the product/community decision, rather than an objection to your implementation.
Reviewed with Codex; I verified the existing assignment workflow and contributor documentation.
中文对照
谢谢你考虑如何让贡献者更容易发现 take / untake。
由于这个改动会在每个新建 issue 下自动添加一条评论,我觉得在决定具体实现之前,最好先和社区讨论这个行为本身。目前贡献指南里已经记录了这些命令,因此也值得先确认现在是否仍然存在可发现性问题,以及自动评论是不是大家更希望采用的解决方式。
可以请你先为这个提议创建一个 Discussion,并在这里关联一下吗?这样贡献者和维护者可以一起权衡它对新贡献者的帮助,以及额外通知和 issue 噪声带来的影响。这只是建议把产品和社区层面的决定放到更合适的地方讨论,并不是对你当前实现的否定。
本次审查使用了 Codex;我核对了现有的 issue 认领 workflow 和贡献指南。
4ee87bd to
681865c
Compare
|
@Astro-Han Thanks for the suggestion. I opened #4160 so the community can discuss the discoverability benefit and notification cost before we move forward with this behavior. |
Astro-Han
left a comment
There was a problem hiding this comment.
The community/product decision from the earlier review still needs human resolution. Separately, the current exact implementation has one repository-policy provenance issue that can be fixed without deciding whether the feature should ship. Review analysis was assisted by Codex and an independent @Reviewer agent. Astro-Han verified the exact-head workflow and policy before publication and owns this review.
Signed-off-by: Jiawei Zhao <Phoenix500526@163.com>
681865c to
d84569a
Compare
hqhq1025
left a comment
There was a problem hiding this comment.
Reviewed exact head d84569a4585220b4b1f34b0a002248389069d917. I found no P0-P3 technical issues in this revision.
The change adds an issues.opened workflow that posts static take / untake guidance. I checked the complete one-file diff against the existing assignment workflow and contributor documentation. The command descriptions match the exact-body behavior, the welcome comment cannot trigger the assignment workflow itself, permissions are limited to issues: write, and the action is pinned to the commit for v5.0.0.
Validation: actionlint v1.7.7, workflow contract assertions, ASF header audit, git diff --check, clean ancestry/merge against current main, and the hosted test check all pass.
The remaining question is product/community policy, not implementation correctness: Discussion #4160 is still open and unanswered, while this change would add a bot comment and notification to every newly opened issue. This technical review should not be treated as approval of that behavior; a maintainer/community decision is still needed before merge.
I did not execute a real issues.opened event because that would require mutating the live repository.
Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.
|
Closed accroding to the discussion: #4160 |
Summary
So many people don't know that they can reply a "take" or "untake" comment to self-assign or self-unassign an issue. This action is designed to leave a comment on an issue to let them know.
Refs #N
Verification
AI use
Select exactly one:
Tool(s) and scope:
Checklist
Does this PR entail a change in behavior?